In recent years, the capacity of storage devices has not increased as fast as the demand for storage. Therefore a given server or other host must access multiple, physically distinct storage nodes (typically disks). In order to solve these storage limitations, the Storage Area Network (“SAN”) was developed. Generally, a storage area network is a high-speed special-purpose network that interconnects different data storage devices and associated data hosts on behalf of a larger network of users. A SAN may use various types of network traffic, but more often than not it employs Fibre Channel frames.
Traditionally, designers of storage area networks built separate fabrics, otherwise known as SAN islands. For example, a business might employ one SAN island for human resources applications, another SAN island for engineering applications, another for marketing, etc. Each SAN island contains a physically isolated switch or a group of switches for connecting hosts to storage devices. While this approach may enforce separation of data between various groups in an organization, it frequently under utilizes hardware and management resources.
More recently, some switches such as the MDS9000 family of switches from Cisco Systems, Inc. of San Jose, Calif. have provided the capability to deploy virtual SANs (“VSANs”). With this approach, a multiple SAN islands may be collapsed to a single physical infrastructure, thereby reducing hardware costs and improving manageability while maintaining the stability and traffic isolation of the SAN island model. Each VSAN is logically separate and may be assigned to a separate group, e.g., marketing, engineering, etc. In this collapsed fabric model, some or all switches and inter-switch links in the fabric carry traffic for multiple VSANs.
In conventional Fibre Channel, each device (e.g., hosts, storage devices and switches) is identified by an unique eight (8) byte wide physical world wide name ID (PWWN) assigned by the manufacturer. When the Fibre Channel devices are interconnected to form a SAN, the PWWN (along with other parameters) is used to identify each device. Each device may also have and associated unique node world wide name ID (NWWN).
Fibre Channel frames are used for communication among the devices in the SAN. The PWWN, however, is not used by the frames. Instead the Fibre Channel Port of each end device (hosts and storage devices) is addressed via a three (3) byte Fibre Channel address (or FCID), allocated dynamically to the end devices by the fabric. A unique FCID is assigned to a host device or disk device when the device logs in to the fabric. Additionally, each switch in the fabric is assigned a specific domain by the domain manager when the switch is connected to the fabric. All the devices connected to a given switch will have the DomainID of the switch as the first byte of their FCIDs. This “Domain” value is used for routing the frames within the fabric. Each FC frame header will include an SID field representing the source FCID, and a DID field representing the destination FCID.
Until now, only the interconnect ports (called “E_Ports”) that connect the VSAN switches could be configured to carry the traffic of multiple VSANs. Therefore, host bus adaptors (“HBAs”) or other interfaces in hosts (e.g., N_Ports) attached to F_Ports or FL_Ports could be configured in one VSAN only.
The VSAN of the attached switch port (also called the “port VSAN”) is implicitly assigned to the HBA and all traffic transmitted or received by the HBA belongs to that VSAN. In this approach, all traffic between the HBA and the switch port is transmitted in standard Fibre Channel frame format, commonly termed “untagged format.”
This should be contrasted with the format of frames exchanged between trunking E_Ports, which are encapsulated in Extended Inter-Switch Link (“EISL”) format, commonly termed “tagged format”. The format specifically identifies the VSAN of each frame and thereby allows enforcement of VSAN specific security policies, quality of service, etc. The use of trunking E_Ports and the EISL format is described in detail in US Patent Publication No. US-2003-0118053-A1, and U.S. patent application Ser. No. 10/979,886, previously incorporated by reference.
Additional information relating to SAN communication protocols are described in the following references, each of which is incorporated herein by reference in its entirety for all purposes: (1) “VF N_Port Support, T11/04-494v1,” by Claudio DeSanti, American National Standards Institute (INCITS), September 2004, www.t11.org; (2) “Fibre Channel Link Services (FC-LS) Rev 1.2,” by Carlson et al., American National Standards Institute (INCITS), Jun. 7, 2005; www.t11.org. For reference purposes, the “VF N_Port Support, T11/04-494v1” may herein be referred to as the “Exchange Virtual Fabric Parameters (EVFP) protocol” standard or simply the “EVFP protocol” standard; and the “Fibre Channel Link Services (FC-LS) Rev 1.2” may herein be referred to as the “FC-LS protocol” standard.
Conventional Fibre Channel VSAN implementations typically require that node devices employ multiple HBAs to connect to multiple switchports—one for each supported VSAN—to achieve multi-homing (participation in multiple VSANs). This redundancy is wasteful. While the deployment of multiple VSANs on a common topology represents a significant advance in storage area network technology, the requirement that a node have a separate physical interface for each of its VSANs presents a significant waste of resources.
Additionally, even in embodiments such as those described in U.S. patent application Ser. No. 10/979,886 where trunking mechanisms are employed to allow multiple HBAs of a given node to be configured in multiple VSANs via a single physical interface and associated F_Port, such embodiments typically require that the node be adapted to include additional mechanisms for allowing each HBA to know its respective VSAN association, and to provide such information to the F_Port during the FLOGI process. In at least some of these embodiments, if a given node or HBA does not include such additional mechanisms, the FLOGI process may fail and/or the use of trunking mechanisms may be disabled, either of which may be undesirable.
Therefore, an improved protocol and apparatus design to provide more efficient use of N_Port and F_Port resources is needed.